\documentclass[a4paper,10pt]{article}
\usepackage[spanish]{babel} %Paquetes de idioma
\usepackage[latin1]{inputenc} %Paquetes de idioma
\usepackage{graphicx} % Paquete para ingresar gráficos
\usepackage{hyperref}
\usepackage{fancybox}

%Encabezado y Pié de página
\input{EncabezadoyPie.tex}
%Carátula del Trabajo
\title{ \input{Portada.tex} }

\begin{document}
	\maketitle %Hace que el título anterior sea el principal del documento
	\newpage

	\tableofcontents %Esta línea genera un indice a partir de las secciones y subsecciones creadas en el documento
	\newpage

	\section{Descripci\'on del Negocio}
		%\vspace{1cm}
		\subsection{Objetivo}
		El sistem esta dirigido a automatizar el proceso de geti\'on de alumnos y grupos de una materia dada via recepci\'on y envio de correos electr\'onicos. Esto se realizar\'a a traves de un sistema de reglas a aplicar a cada email, el cual se podr\'a extender para agregar nuevas funcionalidades. Tambi\'en se encargara de la gesti\'on de una lista de consultas privadas (en donde solo las veran los profesores y ayudantes de la materia) o publicas.

	 	\subsection{Alcance}		
			\begin{itemize}
				\item Configurar cuentas de e-mail de la materia.
				\item Administrar datos de la materia (crear, modificar y eliminar).
				\item Procesar e-mails:
					\begin{itemize}
						\item Alta de alumnos en la base de datos y/o google spreadsheat.
						\item Persistencia de archivos adjuntos en e-mails.
						\item Responder ante e-mails con formato desconocido.
						\item Nuevos temas de discusi\'on.
						\item Alta de grupos en la base de datos.
					\end{itemize}
				\item Consultar temas de discusi\'on.
				\item Asignaci\'on de temas de discusi\'on.
				\item Monitoreo de estado de los temas de discusi\'on.
				\item Ver estad\'isticas.
			\end{itemize}
	\section{Arquitectura Propuesta}
	En las secciones siguientes se da una descripcion de la arquitectura propuesta para desarrollar el sistema basandos\'e en el modelo de \emph{Vistas 4+1} \footnote{ Art\'iculo publicado en IEEE Software 12(6) por Philippe Kruchten, Noviembre 1995.}

Se decidi\'o utilizar una arquitectura basada en capas implementado a traves del patr\'on de arquitectura \emph{LAYERS}, en las cuales se separ\'o la presentaci\'on del modelo de negocio de la persistencia de los datos (esto se detallar\'a mas adelante en la Vista de Desarrollo).


		\subsection{Vista de Desarrollo o de Componentes}
		Las capas en las que se dividi\'o el sistema son:
		\begin{itemize}
			\item Capa de Persistencia: Aqui reside la l\'ogica de persistencia a la base de datos.  
			\item Capa de Acceso a Datos: Ofrece servicios de persistencia y recuperaci\'on de informaci\'on a la capa de negocio.  
			\item Capa de Negocio: Implementa procesos de negocio identificados durante el an\'alisis funcional y expone las funcionalidades necesarias para soportar los casos de uso definidos para la aplicaci\'on. Los mismos ser\'an consumidos por la capa de presentaci\'on. 
			\item Capa de Presentaci\'on: Presenta la informaci\'on al usuario permiti\'endole interactuar con la aplicaci\'on, y traduce los eventos generados en pedidos a la capa de servicio. 
		\end{itemize}
		\begin{figure}[h!]
			\centering
			\includegraphics[width=0.9\textwidth]{img/diagrama_componentes2.png}
			\caption{Diagrama de componentes}
		\end{figure}
\indent Se tom\'o la determinaci\'on de aislar lo m\'as posible a la capa de Negocio de las dem\'as. Son las 
otras capas las que dependen de la capa de negocios. La capa de negocios s\'olo conoce a ciertas interfaces que sirven de comunicaci\'on entre los componentes, pero no conoce a sus implementaciones espec\'ificas.
		
		\vspace{0.5cm}
		\subsection{Vista de Procesos}
		El sistema tiene dos procesos principales corriendo constantemente el cual crean un esquema \emph{productor} - \emph{consumidor}.\\
		\indent El primero, el productor, es \emph{MailRetriever} que a partir de las cuentas de emails configuradas para cada materia, se conecta via \emph{POP} o \emph{IMAP} y descarga los emails de la casilla y los almacena en la Base de Datos, el segundo proceso, el consumidor, es \emph{MailProcessor} el cual levanta los emails descargados de la Base de Datos y los procesa aplicandoles las reglas configuradas.
		\begin{figure}[h!]
			\centering
			\includegraphics[width=1\textwidth]{img/diagrama_procesos.png}
			\caption{Diagrama de procesos}
			\label{diag_procesos}
		\end{figure}
		
		\indent En la Figura \ref{diag_procesos} se puede ver el esquema de los procesos a los cuales se les suma dos procesos, uno es \emph{DataBase} el cual representa el proceso del servidor de Base de Datos y el otro es \emph{MailServer} que representa las casillas de email de las cuales se descargan los emails.
		
		\subsection{Vista L\'ogica}
		En la Figura \ref{diag_clases} se muestra un diagrama de clases para la Capa de Negocio con las clases mas importantes y como es su jerarquia. Aqui se puede ver el \emph{core} de la aplicaci\'on que esta basada en reglas a aplicar a un mensaje, cada una de estas reglas contiene una o mas acciones las cuales son ejecutadas en caso de que la regla aplique.\\
		\begin{figure}[h!]
			\centering
			\includegraphics[width=1\textwidth]{img/diagrama_clases.jpg}
			\caption{Diagrama de clases}
			\label{diag_clases}
		\end{figure}
		\indent Para poder desacoplar al procesador de emails de cada regla en particular se decidi\'o implementar una Cadena de Responsabilidades en donde cada eslab\'on de la cadena es una regla y la petic\'on que circula por la cadena es el mensaje a procesar.\\
		\indent Para el caso de la creaci\'on de las reglas se decidi\'o utilizar el patr\'on Abstract Factory para poder lograr una independencia de como se crean y compone cada regla, de esta forma es se puede cambiar la composic\'on de una regla (sus acciones) de forma facil.\\
		\begin{figure}[h!]
			\centering
			\includegraphics[width=1\textwidth]{img/diagrama_secuencia.jpg}
			\caption{Diagrama de secuencia: Procesamiento de emails}
			\label{diag_secuencia}
		\end{figure}
		\begin{figure}[h!]
			\centering
			\includegraphics[width=1\textwidth]{img/diagrama_secuencia2.jpg}
			\caption{Diagrama de secuencia: Descarga de emails}
			\label{diag_secuencia2}
		\end{figure}
		\indent Tambien se pueden observar los diagrams de secuencia para los casos mas relevantes, uno es el proceso que descarga los emails de la cuanta de la materia configurada en la Figura \ref{diag_secuencia2} y en la Figura \ref{diag_secuencia} se muestra el diagrama para el procesador de emails y la aplicaci\'on de una regla con la ejecuci\'on de sus acciones.\\
		En la capa de persistencia se utiliz\'o el patr\'on DAO, de esta forma la capa de negocio se abstrae del destino de los datos persistidos. Para la interfaz grafica se utilizo el patr\'on MVC asi de esta forma el modelo se abstrae de la representaci\'on de los datos.
		\subsection{Vista Fisica o de Despliegue}
		En la Figura \ref{diag_despliegue} se muestra como se despliega fisicamente el sistema, este consta del \emph{Client} el cual se conecta via http con el browser al Web Server en el cual se pueden configurar materias, y ver algunas estadisticas del envio y recepci\'on de emails. Y finalmente este se conecta via TCP/IP al servidor de Base de Datosque se usa como medio de persistencia de los datos.
		\begin{figure}[h!]
			\centering
			\includegraphics[width=0.9\textwidth]{img/diagrama_despliegue.png}
			\caption{Diagrama de despliegue}
			\label{diag_despliegue}
		\end{figure}
		\subsection{Escenarios}
		Aqu\'i se muestra el proposito del sistema y por que se crearon las otras cuatro vistas, esto se hace a traves de los caso de usos como muestra la Figura \ref{diag_usos}
		\begin{figure}[h!]
			\centering
			\includegraphics[width=1\textwidth]{img/diagrama_casos_uso.jpg}
			\caption{Diagrama de casos de uso}
			\label{diag_usos}
		\end{figure}
		
	\section{Despliegue y puesta en marcha del sistema}
	\subsection{Requerimientos}
	Los requerimientos necesarios para ejecutar el sistema son:
	\begin{itemize}
		\item Servidor Web Apache Tomcat
		\item Servidor de Base de Datos MySQL
	\end{itemize}
	\subsection{Configuraci\'on}
	Los pasos para la configuraci\'on y ejecuci\'on del sistema son los siguientes:
	\begin{enumerate}
		\item Copiar el archivo war del proyecto en la carpeta \emph{webapps} de Apache Tomcat.
		\item Levantar el Servidor Apache Tomcat.
		\item Bajar el el Servidor Apache Tomcat.
		\item Ir a la carpeta \emph{webapps} y buscar la carpeta generada de la app (tiene  el mismo nombre que el war).
		\item Buscar el archivo de configuraci\'on y configurar los datos de conexi\'on a la Base de Datos (usuario, password, direcci\'on IP del servidor, etc) y paths utilizados.
		\item Levantar el servidor de Base de Datos.
		\item Levantar el Servidor Apache Tomcat.
	\end{enumerate}
	\subsection{Uso}
	El sistema posee una interfaz web de administrador en la cual se dan de alta las materias y se configuran los datos de la casilla de email, tanto para descargarlos usando IMAP o POP como para reenviar los emails desde esta. Una vez configurado esto ya se esta en condiciones de empezar a usar el sistema.
	\subsubsection{Reglas}
	El sistema viene con las siguiguientes reglas pre-implementadas:
	\begin{itemize}
	\item \lbrack ALTA-MATERIA-\emph{codigo}\rbrack\emph{padron}-\emph{nombre}: Se da de alta al alumno con \emph{padron} y \emph{nombre} en la materia con codigo \emph{codigo}
	\item \lbrack ENTREGA-TP-\emph{nro}\rbrack: Se recibe adjunto el Trabajo Practico numero \emph{nro}.
	\item \lbrack CONSULTA-PUBLICA/PRIVADA\rbrack \emph{tema}: Se recibe una consulta con tema \emph{tema}, en caso de que sea publica se reenvia a los docentes y a los alumnos inscriptos en la materia, en caso de ser privada se le reenvia solo a los docentes.
	\item \lbrack ALTA-GRUPO\rbrack: Se da de alta un grupo a partir de un archivo adjunto con los padrones de cada integrante.
	\item \lbrack CONSULTA-PUBLICA/PRIVADA-RESUELTA\rbrack \emph{tema}: Se cambia el estado de la consulta con tema \emph{tema} a resuelta. Esta regla valida que el que envia el email sea un docente, en caso contrario no tiene efecto alguno.
	\end{itemize}
	\indent Todas estas reglas aplican sobre el asunto de email enviado.\\
	\subsubsection{Extensi\'on de las Reglas}
	Existe al posibilidad de extender las funcionalidades del sistema agregando reglas a este, esto se hace programando una regla que extienda de la clase ReglaAbstract y un factory para esta que implemente la interfaz ReglaFactoryInterface. Una vez hecho esto se agrega el nombre completo de la clase en el archivo de configuraci\'on y el proceso cargara la regla y la ejecutar\'a.
	
\section{Dise\~no}
	A continuac\'ion se describen los lugares del sistema en donde se aplicar\'on los patrones de sise\~nos vistos en clase:
	\begin{itemize}
		\item Layer: Se dise\~n\'o na arquitectura usando este patr\'on para poder separar la presentaci\'on del modelo de negocio de la persistencia de los datos trabajando entre estas definiendo interfaces.
		\item Cadena de Responsabilidades: Para poder desacoplar al procesador de emails de cada regla en particular se decidi\'o implementar este patr\'on en donde cada eslab\'on de la cadena es una regla y la petic\'on que circula por la cadena es el mensaje a procesar.\\
		\item Abstract Factory: Este patr\'on se utiliz\'o para la creaci\'on de las reglas para poder lograr una independencia de como se crean y compone cada regla, de esta forma es se puede cambiar la composic\'on de una regla (sus acciones) de forma facil.
		\item Singleton: Los DAOs utilizados para la persistencia de las entidades del sistema se implementaron como singletons ya que nos se necesitan tener mas de una instancia de estos.
		\item Template Method: Se utiliz\'o este patr\'on en la clase \emph{AccionCrearConsultaAbstract} en el metodo \emph{aplicarSobre()} ya que en este se define el algritmo esqueleto y en las clases descendientes de se delegan algunos pasos por ejemplo la creacion de la consulta.
		\item MVC: Este se utiliz\'o para separar la vista del modelo.
	\end{itemize}
	
	\section{Problemas no resueltos}
	Algunos de los problemas encontrados a la hora de desarrollar el sistema que no se llegaron a resolver fueron los siguientes:
	\begin{enumerate}
		\item Utilizar un sistema de \emph{Push} en la descarga de emails: A la hora de descargar los emails recibidos a cada cuenta de cada materia se usa un sistema de tipo \emph{pull} en donde nosotros cada cierta cantidad de tiempo le pedimos que nos de los emails nuevos, este proceso responde mas a un sistema de tipo \emph{Push} en donde el servidor nos tendria que notificar de que hay nuevos emails, de esta forma no estamos gastando recursos de mas en caso de que no se encuentren emails nuevos.
		\item Descarga de emails: Para la descarga de emails se piden todos los emails no leidos, esto funciona si la cantidad de emails no es demasiado grande, para el caso en que sean un vol\'umen importante probablemente tendriamos un problema de memoria. Para esto se deberia hacer un wrapper a la libreria utilizada para descargar los emails en donde se realicen pedidos paginados, asi una vez procesada esta se libera memoria y se prosigue con la siguiente pagina.
		\item Identificaci\'on de las consultas: Para identificar cada consulta se utiliz\'o el asunto del email, esto deberia cambiarse ya que se limita a que si existe una consulta con el mismo asunto en otra materia (o en la misma), esta se uniria a la consulta existente en caso de no estar cerrada la primera o el que realiza la consulta recibir''ia un email notificando que la consulta esta cerrada. Esto se resolveria asignandole un identificador unico a la consulta y luego este sera reenviado junto con la consulta a los demas integrantes de la lista para que se siga trackeando la consulta a traves de este identificador.
	\end{enumerate}
	
	
\end{document}


